For Solcast there are specialized functions for retrieving TMY, historical and forecast data. For Meteonorm there is currently only a TMY and a "everthing else" getter function (for the endpoints /observation/training, /observation/realtime, /forecast/basic, and /forecast/precision). What's the reasoning behind implementing get_meteonorm instead of get_meteonorm_observation_training, get_meteonorm_observation_realtime, get_meteonorm_forecast_basic, and get_meteonorm_forecast_precision? There are pros and cons for both variants, but i would argue, that for the end user it's easier if there's a specialized function for every endpoint.

I might be convinced to have a separate function for get_meteonorm_observation and get_meteonorm_forecast with a keyword parameter to switch between the subcases. The main motivation is to reduce the duplicate docstring and reduce the maintenance burden.

I'm not sure what the right answer here is. Maybe @AdamRJensen's proposal is the best balance.

Yes, I see that this is a maintenance nightmare with doc-strings of this size.
I assume messing around with the __doc__ field to share a part of the documentation is not really an option; this becomes unreadable very fast.

Despite that, every request to the API costs the user real money and thus I'm critical about using parameters - instead of separate functions - to decide which endpoint to call.

[...] keyword parameter to switch between the subcases.

@AdamRJensen How would this look like? One option would be to use the exact same signature but the value to the parameter endpoint has to be "basic"/"precision" for get_meteonorm_forecast and "realtime"/"training" for get_meteonorm_observation.
Note that there is no parameter frequency for the /forecast/basic endpoint, thus it would be a good idea to raise a warning or exception if the user uses endpoint="basic", time_step="1min".

@AdamRJensen How would this look like? One option would be to use the exact same signature but the value to the parameter endpoint has to be "basic"/"precision" for get_meteonorm_forecast and "realtime"/"training" for get_meteonorm_observation. Note that there is no parameter frequency for the /forecast/basic endpoint, thus it would be a good idea to raise a warning or exception if the user uses endpoint="basic", time_step="1min".

@maschwanden If we are to split it into separate forecast and observation functions, then this is exactly how I envisioned it. I'm curious what other members of @pvlib/pvlib-maintainer have to say about this.

Also, I've added an error message if the basic forecast is requested with a frequency other than '1_hour'.

@maschwanden Check out the changes in the last commit. Would this approach be ok with you?

If I understand correctly, @maschwanden proposed meteonorm.get_meteonorm_observation_training is similar to the existing solcast.get_solcast_historic function and the meteonorm.get_meteonorm_observation_realtime is similar to the solcast.get_solcast_live function. I would favor API parallelism over concerns about docstrings.

I'm not sure what the right answer here is. Maybe @AdamRJensen's proposal is the best balance.